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Abstract 


New hash algorithms are being developed that may include parameters. 
Cryptographic Message Syntax (CMS) has not currently defined any hash 
algorithms with parameters, but anecdotal evidence suggests that 
defining one could cause major problems. This document defines just 
such an algorithm and describes how to use it so that experiments can 
be run to find out how bad including hash parameters will be. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6210. 
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(http://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
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Le 


Introduction 


At the present time, all hash algorithms that are used in 
Cryptographic Message Syntax (CMS) implementations are defined as 
having no parameters. Anecdotal evidence suggests that if a hash 
algorithm is defined that does require the presence of parameters, 
there may be extensive problems. This document presents the details 
needed to run an experiment so that the community can find out just 
how bad the situation really is and, if needed, either make drastic 
changes in implementations or make sure that any hash algorithms 
chosen do not have parameters. 


In CMS data structures, hash algorithms currently exist in the 
following locations: 


o SignerInfo.digestAlgorithm - holds the digest algorithm used to 
compute the hash value over the content. 


o DigestedData.digestAlgorithm - holds the digest algorithm used to 
compute the hash value over the content. 


o AuthenticatedData.digestAlgorithm - holds the digest algorithm 
used to compute the hash value over the content. 


o SignedData.digestAlgorithms - an optional location to hold the set 
of digest algorithms used in computing the hash value over the 
content. 


o multipart/signed micalg - holds a textual indicator of the hash 
algorithm for multipart signed MIME messages. 


The first three locations hold the identification of a single hash, 
and would hold the parameters for that hash. It's mandatory to fill 
these fields. 


The ASN.1 structures defined for the DigestedData and 
AuthenticatedData types place the digest algorithm field before the 
encapsulated data field. This means that the hash algorithm 
(including the parameters) is fully defined, and therfore can be 
instantiated, before the hash function would start hashing the 
encapsulated data. 


In the ASN.1 defined for the SignedData type, the value of 
SignerInfo.digestAlgorithm is not seen until the content has been 
processed. This is the reason for the existence of the 
SignedData.digestAlgorithms field, so that the set of all digest 
algorithms used can be seen prior to the content being processed. It 
is not currently mandatory to fill in this field, and the signature 
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validation process is supposed to succeed even if this field is 
absent. (RFC 5652 says signature validation MAY fail if the digest 
algorithm is absent.) 


For the case of detached content, the ASN.1 structures need to be 
processed before processing the detached content in order to obtain 
the parameters of the hash function. The MIME multipart/signature 
content type attempts to avoid this problem by defining a micalg 
field that contains the set of hash algorithms (with parameters) so 
that the hash functions can be set up prior to processing the 
content. 

When processing multipart/signed messages, two paths exists: 


1. Process the message content before the ASN.1. The steps involved 
are: 


* Get a set of hash functions by looking at the micalg parameter 
and potentially add a set of generic algorithms. 


* Create a hasher for each of those algorithms. 
* Hash the message content (the first part of the multipart). 


* Process the ASN.1 and have a potential failure point if a hash 
algorithm is required but was not computed. 


2. Process the message content after the ASN.1. The steps involved 
are: 


* Save the message content for later processing. 


* Parse the ASN.1 and build a list of hash functions based on 
its content. 


* Create a hasher for each of those algorithms. 

* Hash the saved message content. 

* Perform the signature validation. 
The first path allows for single-pass processing, but has the 
potential that a fallback path needs to be added in some cases. The 


second path does not need a fallback path, but does not allow for 
single-pass processing. 
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The fallback path above may also be needed for the encapsulated 
content case. Since it is optional to place hash algorithms in the 
SignedData.digestAlgorithms field, the content will be completely 
parsed before the set of hash algorithms used in the various 
SignerInfo structures are determined. It may be that an update to 
CMS is required to make population of the SignedData.digestAlgorithms 
field mandatory, in the event that a parameterized hash algorithm is 
adopted. 


In this document, a new hash function is created that is based on the 
XOR operator and on MD5. MD5 was deliberately used as the basis of 
this digest algorithm since it is known to be insecure, and I do not 
want to make any statements that the hash algorithm designed here is 
in any way secure. This hash function MUST NOT be released as 
shipping code, it is designed only for use in experimentation. An 
example of a parameterized hash algorithm that might be standardized 
is a scheme developed by Shai Halevi and Hugo Krawczyk [RANDOM-HASH]. 


1.1. Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

2.  XOR-MD5 Digest Algorithm 
The XOR-MD5 digest algorithm has been designed to use two existing 
operators, XOR and the MD5 hash algorithm [MD5]. The hash algorithm 
works as follows: 


1. A random XOR string consisting of exactly 64 bytes is created. 


2. The input content is broken up into 64-byte blocks. The last 
block may be less that 64 bytes. 


3. Each block is XOR-ed with the random string. The last block uses 
the same number of bits from the random string as it contains. 


4. The resulting string is run through the MD5 hash function. 


The length of the XOR string was designed to match the barrel size of 
the MD5 hash function. 
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ASN.1 Encoding 
The following ASN.1 is used to define the algorithm: 
mda-xor-md5-EXPERIMENT DIGEST-ALGORITHM ::= { 


IDENTIFIER id-alg-MD5-XOR-EXPERIMENT 
PARAMS TYPE MD5-XOR-EXPERIMENT ARE required 


} 


id-alg-MD5-XOR-EXPERIMENT OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs-9(9) smime(16) id-alg(3) 13 


} 

MD5-XOR-EXPERIMENT ::= OCTET STRING (SIZE(64) ) 

The octet string holds the value of the random XOR string. 
CMS ASN.1 Handling 

The algorithm is added to the DigestAlgorithmSet in [CMS]. 


When this algorithm is used in a signed message, it is REQUIRED that 
the algorithm be placed in the SignedData.digestAlgorithms sequence. 
The algorithm MUST appear in the sequence at least once for each 
unique set of parameters. The algorithm SHOULD NOT appear multiple 
times with the same set of parameters. 


MIME Handling 
This section defines the string that appears in the micalg parameter. 


The algorithm is identified by the string xor-md5. The parameters 
for the algorithm are the hex-encoded Distinguished Encoding Rules 
(DER) ASN.1 encoding. The parameters and the identifier string are 
Separated by a colon. One of the issues that needs to be addressed 
is the fact that this will generate very long data values for 
parameters. These will be too long for many systems to deal with. 
The issue of how to deal with this has been addressed in [RFC2231] by 
creating a method to fragment values. An example content-type string 
that has been fragmented is: 


Content-Type: multipart/signed; 
protocol-"application/pkcs7-signature"; 
micalg*0="Shal, xor-md5:04400102030405060708090a0b0c0d80e0f0011"; 
micalg*1-2"12131415161718191al1b1c1d1e1f102122232425262728292a2b"; 
micalg*22"2c2d2e2f£203132333435363738"; 
micalg*3="393a3b3c3d3e3f30"; boundary=boundar42 
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Arguments could be made that the string should be base64 encoded 
rather than hex encoded. The advantage is that the resulting 
encoding is shorter. This could be significant if there are a 
substantial number of parameters and of a substantial size. Even 
with the above example, it was necessary to break the encoding across 
multiple lines. The downside would be the requirement that the 
micalg parameter always be quoted. 


It may be reasonable to require that whitespace be inserted only on 
encoding boundaries, but it seems to be overly restrictive. 


6. IANA Considerations 
All identifiers are assigned out of the S/MIME OID arc. 
7. Security Considerations 
The algorithm XOR-MD5 is not designed for general-purpose use. The 


hash algorithm included here is designed for running this experiment 
and nothing more. 


This document makes no representation that XOR-MD5 is a secure digest 
algorithm. I believe that the algorithm is no more secure than MD5, 
and I consider MD5 to be a broken hash algorithm for many purposes. 


One known issue with the algorithm at present is the fact that the 
XOR pattern is always 64 bytes long, even if the data is shorter. 
This means that there is a section of the data than can be 
manipulated without changing the hash. Ina real algorithm, this 
should either be truncated or forced to a known value. 
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Appendix A. Examples 


Provided here are a set of simple S/MIME messages [SMIME-MSG] that 
are for testing. The content used is the same as that found in 
Section 2.1 of [SMIME-EXAMPLES]. The certificates and key pairs 
found in [SMIME-EXAMPLES] are also used here. 


The Perl script in Appendix A of [SMIME-EXAMPLES] can be used to 
extract the binary examples from this file. The MIME examples can be 
extracted with a standard text editor. 


Note: The examples presented here have not been independently 
verified. I was unable to use the Microsoft APIs because of the new 
cryptographic hash algorithm. However, for the purposes of this 
experiment, I believe that the form of the messages, which can be 
verified visually as correct, is more important than the question of 
the message validating. 


A.1. Encapsulated Signed Data Example 


This section contains a detached signed data example. The content 
was hashed with the MD5-XOR algorithm defined in this document. The 
signature is performed using RSA with MD5. The signature is wrapped 
as an embedded signed mime message. 


MIME-Version: 1.0 

To: BobRSA@example.com 

From: AliceDss@example.com 

Subject: MD5-XOR example message 

Message-Id: <34567809323489fd.esc@example.com> 

Date: Wed, 16 Dec 2010 23:13:00 -0500 

Content-Type: application/pkcs7-mime; smime-type-signed-data; 
name-smime.p7m; 
micalg*0-2"xor-md5: 0440010203405060708090a05b0c0d0e0f10"; 
micalg*1-2"111213415161718191al1b1c1d1e1f20212223425262728292a2b2c"; 
micalg*2-2"2d2e2f£30313233435363738393a3b3c3d3e3f40" 

Content-Transfer-Encoding: base64 

Content-Disposition: attachment; filename=smime.p7m 


MIIEqAYJKoZIhvcNAQCCOIIEmTCCBJUCAQEXxUTBPBgsqhkiG9wOBCRADDORAAOIDBAUGBw 
gJCgsMDOA4PEBESEwQVFhcYGRObHBOeHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg50js8 
PTA/QDArBgkqhkiG9wOBBwGgHgQcVGhpcyBpcyBzb211IHNhbXBsZSBjb250Z2W50LqCCAi 
SwggInMIIBkKADAgECAhBGNGvHgABWvBHTbi 7/NXXHOMAOGCSqGSIDb3DQEBBQUAMBIXxEDAO 
BgNVBAMTBONhemxSUOEwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMO8wDOQ 
YDVQODEWZCb2JSUOEwgZ8wDOYJKoZIhvcNAQEBBOQADgYOAMIGJAOGBAKnhZ5g/OdVf8qCT 
OV6meYmFyDVdmpFb-x0B2hlwJhcPvaUiODWFbXqYZhRBXM-t3twg7CcmRuBlpN2352R572a 
kzJKN/O7uvRgGGNjOyywcDWVL8hYsxBLjMGAgUSOZPHPtdYMTgXB9T039T2GkB8QX4enDR 
voPGXz jPHCyqaqf rAgMBAAG j f zB 9MAWGA1 UdEWEB / wWOCMAAwDgYDVROPAQH/BAQDAgUgMB 
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8GA1UdIwOYMBaAFOngkCeseCB6mtNM8kI3TiKunji7MBOGA1UdDgOWBBTo9Lhn2LOWpCrz 
Eaop05Vahha0JDAdBgNVHREEF jAUgRJCb2JSUOFAZXhhbXBsZS5jb20wDOYJKoZIhvcNAQ 
EFBOADgYEAe45mxfEQOPXAgTIhxq3tAayEztkqV3p0OW2uUIOXA8uF-Ks2ck4iH-c*4u3fnlB 
YeHk1m354gRVYUW8ZCdEWKG9WXnZHWQ8IdZFsFloM5LqrPFX5YF9mOYl1kaM53nf06Bw7Kd 
x/UQeX8zbwUArdm962XjgRK/tX60ltrcmI2I/PK9MxggHfMIIB2wIBATAmMBIxEDAOBgNV 
BAMTBONhcmxSUOECEEYOa8eAAFa8EdNuLsl1dcdAwTwYLKOoZIhvcNAQkQAwOEQAECAwQFBg 
CICQoLDAOODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLSAvMDEyMwOlNjc4OTo7 
PDOc-POCggcowGAYJKoZIhvcNAQkDMQSGCSqGSIDb3DOEHATAcBgkqhkiG9wOBCQUXxDxcNMD 
kxMjEwMjMyNTAwWjAfBgkqhkiG9wOBCOOxEgOOlmmuYRtXnoPqECtrSd3A*TBvBgkqhkiG 
9wOBCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWF xgZGh 
SCHRAfICEiIwOlJicoKSorLCOuLzAxMjMENTY3ODk60zw9P j9AoQ0GCSqGSIb3DOEBBAUA 
MAOGCSqGSIb3DQEBBAUABIGACIMpfGAIL1yAdRxWdvYKbtuFzlXKnFqo9ui7V5PndjlDut 
yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFAlPAZacTYrEKChFAK18dsqvlFiplvn8BG/ 
ysFUDfbx5VcTG2Md0/NHV-*qj5ihqM*Pye6Urp-*t5jbqVgpZOXSLfP-*pI- 


>sd.bin 
MIIEqAYJKoZIhvcNAQCCOIIEmTCCBJUCAQEXxUTBPBgsqhkiG9wOBCRADDORAAOIDBAUGBw 
[gJCgsMDQ4PEBESEwQVFhcYGRObHBOeHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg50js8 
|PT4/QDArBgkqhkiG9wOBBwGgHgQcVGhpcyBpcyBzb2111HNhbXBsZSBjb250ZW50LqCCAi 
| SwggInMIIBkKADAgECAhBGNGvHgABWvBHTbi 7NXXHQMA0GCSqGS Ib3DQEBBQUAMBI xEDAO 
| BgNVBAMTBONhemxSUOEwHhcNOTkwOTES5MDEwOTAyWhcNMzkxM jMxM 4jM10TU5WjARMQ8wDQ 
ole ee ee E 
OV6meYmFyDVdmpFb-x0B2hlwJhcPvaUiODWFbXqYZhRBXM-t3twg7CcmRuBlpN2352R572a 
| kzJKN/O7uvRgGGNjQyywcDWVL8hYsxBL jMGAgUSOZPHPt dYMTgXB9T039T2GkB80X4enDR 
| voPGXz jPHCyqaqf rAgMBAAG j f zB 9MAWGA1UdEWEB/wQCMAAwDgYDVROPAQH/BAQDAgUgMB 
| 8GA1UdIwOYMBaAFOngkCeseCB6mt NM8k13TiKunji7MBOGA1UdDgQWBBTo9Lhn2LOWpCrz 
| Eaop05Vahha0JDAdBgNVHREEF jAUgRJCb2JSUOFAZXhhbXBsZ85jb20wDQYJKoZIhvcNAQ 
Eos uu ML C M E D i 
| 

| 


YeHk1m354gRVYUW8ZCdEWKG9WXnZHWQ8IdZFsFloM5LqrPFX5YF9mOYl1kaMb53nf06Bw7Kd 
x/UQeX8zbwUArdm962XjgRK/tX60ltrcmI2I/PK9MxggHfMIIB2wWIBATAmMBIxEDAOBgNV 
BAMTBONhcmxSUOECEEYOa8eAAFa8EdNuLsidcdAwTwYLKoZIhvcNAQkQAwOEQAECAwQFBg 
| cCICOoLDAOODxAREhMEFRYXGBkaGxwdHh8gISIjBCUmJygpKissLSAvMDEyMwQlNjc40To7 
| PDO-POCggcowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9wOBCQUxDxcNMD 
kxMjEwMjMyNTAwWjAfBgkqhkiG9wOBCOOxEgOOlmmuYRtXnoPqECtrSd3A-*TBvBgkqhkiG 
9wOBCTQxYjBgME8GCyqGSIb3DQEJEAMNBEABAgMEBQYHCAkKCwwNDg8QERITBBUWF xgZGh 
| SCHRA£ICEiIwQlJicoKSorLCOuLzAxMjMENTY3ODk60zw9P j9AoQ0GCSqGSIb3DQEBBAUA 
[|MA0GCSqGSIb3DQEBBAUABIGACIMpfGAILIyAdRxWdvYKbtuFzlXKnFqo9ui7V5PndjlDut 
| yib02knY7UtGNhg6oVEkiZHxYh/iLuoLOHSFA1PA4ZacTYrEKChF4K18dsqvlFiplvn8BG/ 
Hep ER eee eer 

«sd.bin 


A.2. Multipart Signed Message 


This section contains a detached signed data example. The content 
was hashed with the MD5-XOR algorithm defined in this document. The 
signature is performed using RSA with MD5. The signature is wrapped 
as a detached signed mime message. 
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MIME-Version: 1.0 
To: User2@example.com 
From: BobRSA@example.com 
Subject: MD5-XOR signing example 
Message-Id: <091218002550300.249@example.com> 
Date: Fri, 18 Dec 2010 00:25:21 -0300 
Content-Type: multipart/signed; 
micalg*0-2"xor-md5: 0440010203405060708090a0b0c0d0e0f10"; 
micalg*1-2"111213415161718191alb1c1d1e1f20212223425262728292a25b2c2d2e"; 
micalg*2="2£30313233435363738393a3b3c3d3e3f40"; 
boundary-"----- NextBoundry Fri, 18 Dec 2009 00:25:21"; 
protocol-"application/pkcs7-signature" 


This is a multi-part message in MIME format. 


—————4 =_NextBoundry Fri, 18 Dec 2009 00:25:21 


This is some sample content. 

-—-—---— =_NextBoundry Fri, 18 Dec 2009 00:25:21 
Content-Type: application/pkcs7-signature; name-smime.p7s 
Content-Transfer-Encoding: base64 

Content-Disposition: attachment; filename-smime.p7s 


MIIEiAYJKOoZIhvcNAQCCOIIEeTCCBHUCAQEXxUTBPBgsqhkiG9wOBCRADDORAAOIDBAUGBw 
gJCgsMDOA4PEBESEwQVFhcYGRObHBOeHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg50js8 
PTA/QDALBgkqhkiG9wOBBwGgggIrMIICJzCCAZCgAwIBAgIQRjRrx4AAVrwRO24uzV1xO0D 
ANBgkqhkiG9wOBAQUFADASMRAwDgYDVQODEwdDYXJSUINBMBAXDTk5MDkxOTAxMDkwMloX 
DTM5MTIzMTIzNTk1OVowETEPMAOGA1UEAxMGOm9iUINBMIGfMAOGCSqGSIDb3DQEBAQUAAMA 
GNADCBiQKBgQCpAWeYPznVX/KgkOFepnmJhcglXZqRW/sdAdoZcCYXD7211tAl1hW16mGYU 
QVzPt7clOwnJkbgZaTdt-*WUee9mpMySjfzu7rOYBhjYOMssHAl11S/IWLMQSA4zBgIFEjmTx 
zZ7XWDEAFwfUSN/U9hpAfEF-*HpwOb6Dxl84zxwsqmqgn6wIDAQABo38wfTAMBgNVHRMBAf8E 
AjAAMAAGAl1UdDwEB/WQEAWwWIFIDAfBgNVHSMEGDAWgBTpA4JAnrHggeprTTPJCNO4irp44uz 
AdBgNVHQAEFgQU6PSAZ9izlqOq8xGgKdOVWoYWtCOwWHQYDVRORBBYwFIESQm9iUlNBQGV4A 
YWl1wbGUuY29tMA0GCSqGSIb3DQEBBQUAAAGBAHuOZSXxED8QIEyIcat7QGshM/pKld6dDl 
trlCEFwPLhfirNnJOIh/uLt359QWHh5NZt-teIEVWFFvGOnRMChvV152R1kPCHWRbBdaDOS 
6gzxV-WBfZjmNZGjOd5390gcOyncflEHl1/M28FAK3Zvetl44ESv7V-*qJba3JiNiPzyvTIMY 
IB3zCCAdsCAQEwJjASMRAwDgYDVQODEwdDYXJSUINBAhBGNGvHgABWvBHTbi7NXXHOME8G 
CyqGSIb3DQOEJEAMNBEABAgMEBOYHCAkKCWWNDg8QERITBBUWFxgZGhscHRAfICEilwQlJi 
coKSorLCOuLzAxMjMENTY3ODk60zw9Pj9AoIHKMBgGCSqGSIDb3DOEJAzELBgkqhkiG9w0B 
BwEwWHAYJKoZIhvcNAQOkFMQ8XDTEWMTIXxMDIzMjUwMFowHwYJKoZIhvcNAQkEMRIEEJZprm 
EbV56D6hAra0ndwPkwbwYJKoZIhvcNAQkOMWIwYDBPBgsqhkiG9wOBCRADDORAAQIDBAUG 
BwgJCgsMDOQA4PEBESEwQVFhcYGRObHBOeHyAhlIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg5Oj 
s8PT4/QKENBgkqhkiG9wOBAQQOFADANBgkqhkiG9wO0BAQQFAASBgEDMeyAkXMYqg / wW2B3P 
i8HWwGnZVA/4muJJ7-*dEPacv3bRqE7n4dPOvXIYR7TJleRJk9uB/wry2fRPcnG3Y/RnO0Jy 
CqXsbtdXXfwOGK/rvLvJOloXUCy4-*HxQk6eaYIBrjiVIUSgZjpZXGJcZg2xq5yHle4aw5Ov 
fOlfOXPiKpll 


S=s45= =_NextBoundry Fri, 18 Dec 2009 00:25:21-- 
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A.3. Authenticated Data Example 


This section contains an authenticated data example. The content was 
hashed with the MD5-XOR algorithm defined in this document. The 
authentication was done with the HMAC-SHA1 algorithm. The key is 
transported using RSA encryption to BobRSASignByCarl certificate. 


MIME-Version: 1.0 

To: BobRSA@example.com 

From: AliceDss@example.com 

Subject: MD5-XOR example message 

Message-Id: <34567809323489fd.esc@example.com> 

Date: Wed, 16 Dec 2010 23:13:00 -0500 

Content-Type: application/pkcs7-mime; smime-type-authenticated-data; 
name-smime.p7m; 
micalg*0-2"xor-md5: 0440010203405060708090a05b0c0d0e0f10"; 
micalg*1-2"111213415161718191alb1c1d1e1f20212223425262728292a25b2c2d2e"; 
micalg*2="2£30313233435363738393a3b3c3d3e3f40" 

Content-Transfer-Encoding: base64 

Content-Disposition: attachment; filename=smime.p7m 


MIICRQYLKOoZIhvcNAQkOAOKgggIOMIICMAIBADGBwDCBvQIBADAmMBIXEDAOBgNVBAMMBO 
NhemxSUOECEEYOa8eAAFa8EdNuLsldcdAwDQYJKoZIhvcNAQEBBOAEgYCH7OEpEikY7deb 
859YJRAWfFondQv1DANFltw6ClceheWnlAUOC2WEXr3LUBXZpl/PSte29FnJxu5bXCTnlg 
elMm6zNl1ZNWNdOKadVBcaxiln8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSknlJu7fgU 
5j2g3bZ2/IM8nHTcygjAKBggrBgEFBOSgBAqFPBgsqhkiG9wOBCRADDORAAQIDBAUGBwgJCg 
SMDQAPEBESEwQVFhcYGRObHBOeHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg50js8PT4/ 
ODArBgkqhkiG9wOBBwGgHgOcVGhpcyBpcyBzb2111IHNhbXBsZSBjb250Z2W50LqKBxzAYBg 
kghkiG9wOBCOMxCwYJKoZIhvcNAQcBMBwGCSqGSIDb3DOQEJBTEPFwOwOTEyMTAyMzI1MDBa 
MB8GCSqGSIb3DQEJBDESBBCWaa5hGleeg-*oQK2tJ3cD5MGwGCSqGSIb3DQEJNDFfMFOwTw 
YLKoZIhvcNAQkQAwOEQAECAwQFBgQCICQOLDAOODXxAREhMEFRYXGBkaGxwdHh8gISIjBCUm 
JygpKissLSA4vMDEyMwOQl1Njc4OTOo7PDO-«POCiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb 
EIbVbg2xq1l 


|>ad.bin 
|MIICRQYLKoZIhvcNAQkQAQKgggIOMIICMAIBADGBwDCBvQIBADAmMBIxEDAOBgNVBAMMBO 
| NhcmxSUOECEEYOa8eAAFa8EdNuLsidcdAwDQYJKoZIhvcNAQEBBQAEgYCH70EpEikY7deb 
|[859YJRAWfFondQv1DANFltw6ClceheWnlAUOC2WEXr3LUBXZpl/PSte29FnJxu5bXCTnlg 
|e1Mm6zN1ZNWNdOKadVBcaxiln8L52tVM5sWFGJPO5cStOyAka2ucuZM6iAnCSknlJu7fgU 
5j2g3bZ/IM8nHTcygjAKBggrBgEFBOgBAqFPBgsqhkiG9wOBCRADDQRAAQIDBAUGBwgJCg 
SMDQAPEBESEwQVFhcYGRObHBOeHyAhIiMEJSYnKCkqKywtLi8wMTIzBDU2Nzg50js8PT4/ 
|ODArBgkqhkiG9wOBBwGgHgQcVGhpcyBpcyBzb2111HNhbXBsZSBjb250ZW50LgKBxzAYBg 
[kqhkiG9wOBCOMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFwÜwOTEyMTAyMzI1MDBa 
| MB8GCSqGSIb3DQEJBDESBBCWaa5hGleeg-toQK2tJ3cD5MGwGCSqGSIDb3DQEJNDFfMFOwTw 
| YLKoZIhvcNAQkQAwOEQAECAwQFBgcICQoLDAOODxAREhMEFRYXGBkaGxwdHh8gISIjBCUm 
JygpKissLS4vMDEyMwOQlNjc4OTo7PDO-POCiCgYIKwYBBQUIAQIEFLjUxQ9PJFzFnWraxb 
E 

|<ad.bin 
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Appendix B. 2008 ASN.1 Module 


The ASN.1 module defined uses the 2008 ASN.1 definitions found in 
[ASN.1-2008]. This module contains the ASN.1 module that contains 
the required definitions for the types and values defined in this 
document. The module uses the class defined in [CMS-ASN] and 
[RFC5912]. 


MD5-HASH-EXPERIMENT 
( iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs-9(9) smime(16) modules(0) 
id-mod-MD5-XOR-EXPERIMENT (999) } 
DEFINITIONS IMPLICIT TAGS ::- 
BEGIN 
IMPORTS 


-- Cryptographic Message Syntax (CMS) [CMS] 


DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 
SignatureAlgorithmIdentifier, DIGEST-ALGORITHM 
FROM  CryptographicMessageSyntax-2009 
( iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs-9(9) smime (16) modules(0) id-mod-cms-2004-02(41) } 


-— Common PKIX structures [RFC5912] 


ATTRIBUTE 
FROM PKIX-CommonTypes-2009 
{ iso(1) identified-organization(3) dod(6) internet (1) 
security(5) mechanisms(5) pkix(7) id-mod(0) 
id-mod-pkixCommon-02 (57) }; 


mda-xor-md5-EXPERIMENT DIGEST-ALGORITHM ::= { 
IDENTIFIER id-alg-MD5-XOR-EXPERIMENT 
PARAMS TYPE MD5-XOR-EXPERIMENT ARE required 


} 


id-alg-MD5-XOR-EXPERIMENT OBJECT IDENTIFIER ::= { 
iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs-9(9) smime(16) id-alg(3) 13 


} 
MD5-XOR-EXPERIMENT ::= OCTET STRING (SIZE (64) ) 


END 
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